‫So cross site request forgery or SRF is another session management problem.
‫So this vulnerability hits the all the applications that set their authentication and session management
‫mechanisms solely on the use of cookies.
‫And yeah, I said earlier that Web applications use cookies for differentiating users, but I certainly
‫did not say that this is 100 percent secure.
‫So allow me to explain.
‫Think of what you need to put into an HDP request when you perform an action on an application.
‫You need to submit both the data and the session and to the Web server.
‫Now, that way the server will understand it as your legitimate request and then it processes it.
‫So the server can differentiate you by your session ID.
‫And if somehow someone uses your session ID instead of you, what can happen?
‫Well, here's where the problem arises.
‫So let's see what we have.
‫Open carry, as always, and log in to be web.
‫Now, open cross site request forgery with the change password option from the menu.
‫And here are several CSR scenarios here.
‫And we're going to look at how they work, so the first one is a password change form.
‫So also open burb and enable foxy piroxicam.
‫And let's type something to change a password.
‫And we have a request in berp.
‫And this is the password change request.
‫And this is a legitimate request, right?
‫So I'm going to send it to the compare tool.
‫And forward it.
‫And looky here, the password has been changed, so now, right, click and view the page source.
‫Here's a source of the form.
‫This form produces the previous request.
‫So don't you wonder if you use the same form in your application, so now send the request to be Web?
‫How would be to behave in a situation like this?
‫Why don't we have a look?
‫So open up your terminal.
‫Now, I quoted this page, which produces this same request as a password change form, you can download
‫it from here.
‫So here's an iFrame, which requests a password change from Web.
‫And we also have a second option.
‫And this one's almost the same as the actual form.
‫So let's look at the values, so these are the values that we want to set as password.
‫And the form submitted by a JavaScript code when the page opens.
‫OK, now I'm going to clear all the information in Firefox and I'm going to open one of these pages
‫from County directly.
‫Remember to enable berp.
‫Now, double click this one, and it will immediately open in a browser and Birbal capture it.
‫So it's similar to the previous one, right?
‫So send it to compare as well.
‫You can drop it.
‫And here's a source of the page.
‫OK, so go to compare her.
‫So Compar is yet another valuable tool in burb sweet.
‫And both requests are here.
‫And now click on words in order to compare them word for word.
‫And here is a result.
‫So the request on the right is our fake request.
‫Is almost the same to the actual one.
‫Can you see the difference?
‫There's an important small header.
‫So it's not the same, it's the cookie cutter.
‫The request on the left is a legitimate and authenticated request.
‫The other is not so the browser adds the cookie to the original request.
‫Because the actual user triggers a password change form.
‫So anyway, we can create such a fake request, but we cannot send it to the server on behalf of the
‫actual user because we need the users session ID.
‫So we need to force the user to open our page while he is displaying the same page.
‫OK, so close it up and clear.
‫So I'm going to go back to burb here again and I will open that page and remember to enable berp.
‫So I'm going to change the password again.
‫Send it to compare as well.
‫OK, so as a victim, I'm displaying the page that contains an insecure form.
‫Now, at the same time, I'll open a suspicious application in another tab in the same browser.
‫And again, you need to use some social engineering techniques in order to deceive the victim.
‫I almost forgot to enable berp again.
‫OK, so refresh the suspicious page.
‫And this is a fake request.
‫Send it to compare as well.
‫And just leave it.
‫Now, go to compare.
‫And click to see the difference between them.
‫So this time, there is no important difference because the browser tries to request a server that is
‫the server of the application that's open in another tab.
‫So our fake request will go to the B Web server.
‫And naturally, the browser adds a cookie header to the request.
‫So now there is the user session ID in our FAQ request.
‫So that way we can change the user's password.
‫It's also an example of insecure resat or the change function in applications.
‫All right, so go ahead and close it.
‫And on this show, the result.
‫So go to my admin interface, a B box.
‫And then browse the user's table.
‫And this is the changed password.
‫So search it on Google.
‫Go to the first one.
‫And here is a result, we're able to change the victim's password.